Client Version Log

I want to monitor the client version of users logging in to DOORS during an upgrade, anyone know an easy way of logging this?


Chris Palmer - Wed Jul 10 03:57:01 EDT 2013

Re: Client Version Log
Mike.Scharnow - Wed Jul 10 16:23:13 EDT 2013

at http://www-01.ibm.com/support/docview.wss?uid=swg21399206, IBM says:
"You may also check login_history file to check log in history under $DOORSHOME$\data\v6data\logs (example: C:\Program Files\IBM\Rational\DOORS\9.x\data\v6data\logs)"

 

Perhaps you will want to share the logs directory (network share), so that a client may get the desired information?

 

HTH
Mike

Re: Client Version Log
llandale - Sat Jul 13 12:03:41 EDT 2013

Mike's reference shows which client's have logged in when; it doesn't show the DOORS version of those clients.

Best I came up with years ago was a post-module-open trigger that does this:

  • Puts today's date and the user name together into a file name
  • If this file name exists then exit and do nothing (client information already logged for this user today)
  • Open a config file, and store information about the client
    • Client version
    • User
    • Addins
    • Client PC OS
    • Module opened, which suggests which Project this user is primarily assigned
    • couple other things
  • have a proghram to query these files

There is no such "database login trigger"; so I simulate one with a open-first-module trigger.  I'm thinking for your limited use, you could have a post-module-open trigger:

  • Gets the client PC name and client DOORS version
  • Opens a config file with same name as the client PC name
  • insert the DOORS version therein.
  • save the config file.
  • Config file names could look like "ClientVersion/<PCName>" which will put them into a confif-file subdirectory.
  • config area should be "system".

Such a simple trigger is unlikely to take more than a small fraction of a second so folks won't notice.  Perhaps have the trigger halt unless the module is opened visibly; which will (slightly) speed things up for DXL scripts doing chores.

-Louie

Re: Client Version Log
Chris Palmer - Mon Jul 15 04:20:09 EDT 2013

llandale - Sat Jul 13 12:03:41 EDT 2013

Mike's reference shows which client's have logged in when; it doesn't show the DOORS version of those clients.

Best I came up with years ago was a post-module-open trigger that does this:

  • Puts today's date and the user name together into a file name
  • If this file name exists then exit and do nothing (client information already logged for this user today)
  • Open a config file, and store information about the client
    • Client version
    • User
    • Addins
    • Client PC OS
    • Module opened, which suggests which Project this user is primarily assigned
    • couple other things
  • have a proghram to query these files

There is no such "database login trigger"; so I simulate one with a open-first-module trigger.  I'm thinking for your limited use, you could have a post-module-open trigger:

  • Gets the client PC name and client DOORS version
  • Opens a config file with same name as the client PC name
  • insert the DOORS version therein.
  • save the config file.
  • Config file names could look like "ClientVersion/<PCName>" which will put them into a confif-file subdirectory.
  • config area should be "system".

Such a simple trigger is unlikely to take more than a small fraction of a second so folks won't notice.  Perhaps have the trigger halt unless the module is opened visibly; which will (slightly) speed things up for DXL scripts doing chores.

-Louie

We have a trigger set which operates when a module opens, I have been using this to monitor users but it produces a lot of log information. Will probably stick with this.

Re: Client Version Log
llandale - Tue Jul 16 14:31:53 EDT 2013

Chris Palmer - Mon Jul 15 04:20:09 EDT 2013

We have a trigger set which operates when a module opens, I have been using this to monitor users but it produces a lot of log information. Will probably stick with this.

that's why I used a file name with the user and date in it; if the file already exists no further logging is done.  In your case perhaps you can set a flag in the "top" context to make sure you log only once per DOORS session.  Maybe someone can show us how to do that.